Code Review: Exposes custom properties in SpEL policy rule conditions while resolving deserialization and caching issues. Refactoring is required to address silent failures in seed data initialization, excessive method complexity in fillReadBundle, and inefficient list streaming.

1. ⚠️ Edge Case: initSeedDataFromResources now silently continues on failure
   Files: openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java:1231-1241

   The try/catch added around `initializeEntity(entity)` means that if a critical seed entity (e.g. a default policy, role, or bot) fails to initialize, the system will start up with missing seed data rather than failing fast. The previous behavior propagated the exception, halting seed loading and surfacing the problem immediately.
   
   While resilience against one bad seed entity is useful, silently continuing could leave the system in a subtly broken state (e.g. missing the `ingestion-bot` or a default admin role). Consider distinguishing between optional and required seed entities, or at minimum collecting all failures and throwing at the end if any occurred.

   Suggested fix:
   // After the loop, fail if any critical seed entity was skipped:
   List<String> failures = new ArrayList<>();
   for (T entity : entities) {
     try {
       initializeEntity(entity);
     } catch (Exception e) {
       LOG.warn("Failed to init {} '{}'", entityType, entity.getFullyQualifiedName(), e);
       failures.add(entity.getFullyQualifiedName());
     }
   }
   if (!failures.isEmpty()) {
     throw new IOException("Failed to initialize seed entities: " + failures);
   }

2. 💡 Quality: fillReadBundle has 6 params and 3 boolean tracking vars
   Files: openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java:1655-1669

   The `fillReadBundle` method (lines 1655-1813) is ~160 lines long with 5 parameters, 3 boolean state-tracking variables, and multiple nested branches. Per the project's complexity guidelines (max 15 lines/method, max 5 params), this method would benefit from being decomposed. For example, the cache-hit path (lines 1665-1684), the DB-fetch path (lines 1689-1724), and the cache-populate path (lines 1756-1765) are each self-contained and could be extracted.

3. 💡 Performance: insertVersionExtensionsWithMetadata streams list 6 times
   Files: openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java:2597-2611

   In `insertVersionExtensionsWithMetadata` (lines 2597-2618), the `versionExtensionRecords` list is streamed 6 separate times to extract each field into its own list. For large batch imports this is wasteful. A single loop collecting all fields simultaneously would be more efficient and more readable.

   Suggested fix:
   List<UUID> ids = new ArrayList<>(versionExtensionRecords.size());
   List<String> exts = new ArrayList<>(versionExtensionRecords.size());
   // ... etc for each field
   for (var r : versionExtensionRecords) {
     ids.add(r.getId());
     exts.add(r.getExtension());
     jsons.add(r.getJson());
     versions.add(r.getVersionNum());
     keys.add(r.getChangedFieldKeys());
   }
   daoCollection.entityExtensionDAO()
     .insertVersionExtensions(ids, exts, entityType, jsons, versions, keys);

4. 💡 Quality: extractFqn line exceeds typical length limit
   Files: openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java:3262

   Line 3262 (`return node.hasNonNull("fullyQualifiedName") ? node.get("fullyQualifiedName").asText() : null;`) contains the magic string `"fullyQualifiedName"` repeated twice. Per the 'no magic strings' guideline, this should use the existing `FIELD_FULLY_QUALIFIED_NAME` constant (or equivalent) from the Entity class.